Building the IBM 4758 Secure Coprocessor

W ork leading toward the IBM 4758 started, arguably, in the 1980s when the Abyss project began exploring techniques to build tamper-responsive hardware and use that technology to protect against software piracy. 1,2 Influenced by this earlier work, we sought to build a secure coprocessor, defined as a tamper-responding device derived from the Abyss, Citadel, and 4755 work. We wanted to provide a single multipurpose platform that third parties could use to develop and deploy secure coproces-sor applications, with minimal IBM participation. To accomplish this, we sought to achieve several goals: • Ensure that the device can be identified externally as to contents, using some form of outbound authentication and public-key interface (PKI). • Design the device and its software to be securely configurable and updatable in the field. • Construct the software architecture to accommodate layers of code from different parties, who may or may not trust each other. • Avoid letting the compromise of one device breach the security of another. • Validate all these assertions through an external party. IBM's Common Cryptographic Architecture product group realized that its next-generation product required properties possessed by the secure coproces-sor that IBM Research advocated. This knowledge gave the research team a unique and perhaps nonre-peatable opportunity: funding and authority to design and produce the product we thought should exist, as long as it could be transformed into a CCA follow-on and meet the appropriate deadlines. Seeking to provide an environment where applications could run securely forced us to focus not only on security mechanisms and their implementation and management, but also on various flavors of security policies they must support. Clearly, the hardware on which applications run must be secure, as must the operating system and runtime environment in between, while offering a reasonable API for applications developers. To fix problems in the field and enable fast and inexpensive reaction to changing customer needs, we implemented part of the code as firmware, rather than read-only memory. Figure 1 shows the 4758's three major components and their interrelationships. Subdividing the software into different layers raises issues of trust because upper components rely on the security that lower layers offer. Applications cannot be more secure than the kernel functions they call, and the operating system cannot be more secure than the hardware that executes its commands. Thus, if the lower layers are robust, higher layers can choose whether to relinquish some security. …